Compliance-Vorgaben für die regulierte Bereitstellung

Ein multinationales Unternehmen, das mit Upsun arbeitet, betreibt mehr als 400 Websites. Jede Tochtergesellschaft hat ihre eigenen Websites, ihr eigenes Team, ihren eigenen Release-Zeitplan und ihre eigenen lokalen Anforderungen. Was sie gemeinsam haben, ist eine einzige Infrastruktur-Kontrollschicht: dasselbe Zugriffsmodell, dieselben Verschlüsselungsstandards, dieselben Aktivitätsprotokolle, dieselbe Region und dieselbe Richtlinie für backups bei jedem Projekt. Das Hinzufügen der 401. Website bedeutet nicht, dass ein 401. Satz von Infrastrukturkontrollen hinzukommt, den jemand überprüfen muss. 

Das ist das Ergebnis, auf das es sich zu hinarbeiten lohnt, denn jeder IT-Leiter mit Compliance-Verantwortung stößt irgendwann an dieselbe Grenze. Das Entwicklerteam will die Geschwindigkeit erhöhen. Die Compliance-Abteilung braucht den Nachweis, dass dabei nichts gefährdet wurde. 

In der Vergangenheit wurden diese beiden Anforderungen durch Prozesse in Einklang gebracht: manuelle Überprüfungen, Change-Advisory-Boards und Release-Freezes vor Audit-Fenstern. Diese Abstimmung funktioniert zwar, ist aber langsam und lässt sich nur schlecht skalieren. Was skaliert, ist nicht die Anzahl der Anwendungen, sondern die Anzahl der regulierten Releases. Eine Handvoll sensibler Anwendungen, die mehrmals pro Woche veröffentlicht werden, kann denselben Überprüfungsaufwand verursachen wie Hunderte unauffälliger Anwendungen – weshalb das Zählen von Anwendungen das Problem unterschätzt.

Die Alternative wendet dieselbe Strenge eine Ebene tiefer an – auf der Plattform, über die jedes Team ohnehin schon veröffentlicht –, sodass sie nicht von jedem Team bei jedem Release erneut angewendet werden muss.

Wo Schutzmaßnahmen angesiedelt sein müssen

Wichtigste Erkenntnis: Leitplanken gehören auf die Plattformebene, nicht auf die Anwendungsebene. Alles, was jedes Mal korrekt sein muss – unabhängig davon, was ein Team entwickelt –, sollte strukturell durchgesetzt und nicht manuell geprüft werden.

Die Referenzarchitektur unterteilt die Bereitstellung in zwei Ebenen mit einer klaren Abgrenzung zwischen ihnen: eine Schutzebene, die die Plattform konsistent auf jedes Team und jedes Release anwendet, und eine Anwendungsebene, auf der Teams sinnvolle Entscheidungen im Rahmen der von der Plattform unterstützten Möglichkeiten treffen können.

• Zugriff und Identität. Wer in welche Umgebung deployen darf und in welcher Rolle, sollte einmalig definiert und in jedem Projekt konsequent durchgesetzt werden. Das ist die Ebene, auf die die Anforderungen an die Zugriffskontrolle nach SOC 2 und ISO 27001 abzielen: nicht, ob ein Richtliniendokument existiert, sondern ob der Zugriff nachweislich abgegrenzt und überprüft wird. Upsun bietet rollenbasierte Berechtigungen über Organisationen, Projekte und Umgebungstypen hinweg. Die organisationsweite Durchsetzung von MFA und SSO sind Zusatzfunktionen und keine Standardeinstellungen; daher hängt das Zugriffsmodell, das ein Prüfer sieht, davon ab, welche davon die Organisation aktiviert hat.
• Verschlüsselung und Datenschutz. Verschlüsselung im Ruhezustand und bei der Übertragung, Schlüsselverwaltung und der Umgang mit vertraulichen Daten sollten Plattformstandard sein und nicht projektbezogene Konfigurationsentscheidungen. Ein Team, das einen neuen Dienst entwickelt, sollte nicht entscheiden müssen, ob Daten verschlüsselt werden sollen; diese Entscheidung sollte bereits für sie getroffen sein.
• Aktivitätsprotokolle in Verbindung mit der Änderungsgenehmigung. Upsun protokolliert automatisch für jedes Projekt Bereitstellungen, Pushes, Konfigurationsaktivitäten und den Zugriff auf Umgebungen – mit Zeitstempeln, dem verantwortlichen Nutzer und dem resultierenden Bereitstellungsstatus. Doch Ausführungsprotokolle belegen nur, was passiert ist, nicht aber, dass es genehmigt wurde. Erst die Kombination mit der Pull-Request-Prüfung, bei der ein separater Genehmiger vor dem Merge seine Zustimmung erteilt, schließt diese Lücke im Rahmen der Änderungskontrollen. Eine Ausnahme: SSH-Sitzungsprotokolle sind für Kunden nicht direkt zugänglich und erfordern bei einem Audit möglicherweise eine Supportanfrage bei Upsun.
• Regionsauswahl. Wo regulierte Daten gespeichert werden dürfen, sollte eine kontrollierte Eigenschaft des Projekts sein – und keine Konvention, bei der man darauf vertraut, dass die Teams sich daran halten. Bei Upsun wird die Projektregion bei der Projekterstellung ausgewählt und bleibt dann eine kontrollierte Eigenschaft dieses Projekts, die über den Projektstatus und die Aktivitätsdaten einsehbar ist. Sie wird nicht in der versionsverwalteten Konfiguration deklariert, kann also nicht von einem Team in einem Pull-Request geändert werden. Das bedeutet: Die Antwort auf die Frage „Wo befinden sich diese Daten?“ ergibt sich aus einer Abfrage des aktuellen Projektstatus und nicht aus einem Dokument, das jemand separat überprüfen muss.
• Tests für Backups, Wiederherstellung und Recovery. Automatisierte, geplante Backups mit konfigurierbarer Aufbewahrungsdauer je nach Umgebungstyp sind eine Grundvoraussetzung sowohl nach den Verfügbarkeitskriterien von SOC 2 als auch nach PCI DSS – doch der Zeitplan ist nur die halbe Miete. Upsun führt standardmäßig täglich automatisierte backups der Produktionsumgebungen durch, wobei die Aufbewahrungsdauer so konfigurierbar ist, dass sie dem von einem bestimmten Rahmenwerk geforderten Recovery Point Objective entspricht. Die andere Hälfte liegt beim Kunden. Die Wahl einer Aufbewahrungsdauer, die zum Rahmenwerk passt, und der Nachweis, dass ein Backup wiederhergestellt werden kann, sind Entscheidungen, die die Plattform nicht für dich trifft – und beides gehört zu einem regelmäßigen Überprüfungsrhythmus.

Keine dieser fünf Leitlinien sollte etwas sein, über dessen gute oder schlechte Umsetzung ein einzelnes Team entscheidet. Sie bilden die Grundlage, auf der jede Veröffentlichung steht, und werden durch dieselben Kontrollmaßnahmen umgesetzt, egal ob das Team eine neue, kundenorientierte Funktion oder einen Backend-Dienst veröffentlicht, den niemand sieht. Aufbewahrungsdauer, Region und Zugriffsbereich werden weiterhin pro Projekt festgelegt. Was sich nicht ändert, ist der Mechanismus, der sie festlegt, oder die Nachweise, die sie liefern.

Was flexibel bleibt

Kernaussage: Sobald die Leitplanken-Ebene festgelegt ist, liegen die Entscheidungen darüber beim Team – im Rahmen der Möglichkeiten, die die Plattform unterstützt. Compliance erfordert keine Standardisierung von Dingen, die keinen Einfluss auf die Audit-Situation haben.

Das ist der entscheidende Unterschied, der darüber entscheidet, ob eine Compliance-Architektur angenommen oder umgangen wird. Teams, die Compliance als Einschränkung bei jeder Entscheidung empfinden, werden Auswege finden. Teams, die sie als festes Fundament betrachten, über das sie nicht nachdenken müssen – mit echter Freiheit darüber –, werden das System so nutzen, wie es vorgesehen ist.

• Sprache und Framework. In welcher Sprache ein Dienst geschrieben ist, hat keinen Einfluss darauf, ob Zugriffskontrollen, Verschlüsselung und Audit-Protokollierung korrekt angewendet werden. Das bleibt eine Entscheidung des Teams.
• Release-Rhythmus. Manche Teams veröffentlichen mehrmals am Tag; andere arbeiten in einem langsameren, bedächtigeren Zyklus. Keines der beiden Tempo ist mehr oder weniger konform, vorausgesetzt, die Guardrail-Ebene ist in beiden Fällen konsistent. Eine standardisierte Delivery-Pipeline unterstützt beide, ohne einen einheitlichen Release-Rhythmus zu erzwingen.
• Architektur und Service-Abhängigkeiten. Die Wahl der Datenbank, die Caching-Strategie, interne Service-Grenzen: Das sind produktbezogene und technische Entscheidungen, die dem Team obliegen, das am nächsten am Problem sitzt. Die „Guardrail“-Schicht schreibt nicht vor, was ein Team entwickelt, sondern nur, wie das Entwickelte bereitgestellt, aufgerufen und nachverfolgt wird.
• Sicherheit und Autorisierungslogik auf Anwendungsebene. Die Sicherheitsvorkehrungen der Plattform sichern die Infrastrukturebene ab: Wer darf bereitstellen, wie werden Daten verschlüsselt, wie wird der Zugriff protokolliert? Was ein Team darauf aufbaut, liegt ganz in seiner Verantwortung – einschließlich Anwendungsschwachstellen, Risiken durch Abhängigkeiten und Softwarezusammensetzung sowie der eigenen Logik zur Benutzerauthentifizierung und -autorisierung. Das ist die Grenze der geteilten Verantwortung, die in der Praxis am wichtigsten ist, und es lohnt sich, hier präzise zu sein, anstatt zu implizieren, dass die Plattform alles abdeckt.

Abgleich der Architektur mit bestimmten Frameworks

Wichtigste Erkenntnis: SOC 2, ISO 27001, DSGVO, PCI DSS und DORA bewerten auf der Infrastrukturebene alle dasselbe: Kontrollen, die man nachweisen kann, statt nur zu beschreiben – doch sie sind nicht austauschbar. Jede berücksichtigt unterschiedliche Aspekte und erfordert eine Beurteilung, die keine Infrastrukturebene von sich aus liefern kann.

• SOC 2 Typ 2 bewertet, ob Kontrollen während eines Prüfungszeitraums – typischerweise drei bis zwölf Monate – tatsächlich funktionieren, und nicht nur, ob sie dokumentiert sind. Automatisierte Zugriffsprotokollierung und Verschlüsselung entsprechen direkt den Common Criteria für Sicherheit; automatisierte, getestete backups entsprechen den Verfügbarkeitskriterien. SOC-2-Prüfer unterscheiden zudem zwischen Nachweisen der Ausführung (eine Bereitstellung hat stattgefunden) und Nachweisen der Autorisierung (sie wurde vor der Durchführung ordnungsgemäß geprüft) – genau deshalb ist die Verknüpfung von Plattform-Aktivitätsprotokollen mit Git-basierten Genehmigungsworkflows wichtiger als die Protokolle allein.
• ISO 27001 ist in erster Linie eine Norm für Managementsysteme und erst in zweiter Linie eine Sammlung technischer Kontrollmaßnahmen. Der Kern einer ISO 27001-Zertifizierung ist ein risikogeleitetes Informationssicherheits-Managementsystem: Risikobewertung, Maßnahmenpläne, Management-Überprüfungszyklen und eine Gültigkeitserklärung. Die technischen Kontrollmaßnahmen, die eine Guardrail-Architektur erfüllt – Zugriffskontrolle, Kryptografie, Protokollierung –, fallen unter Anhang A und unterstützen das ISMS; sie ersetzen jedoch nicht die Governance-Maßnahmen, die der Standard tatsächlich verlangt.
• Die DSGVO schreibt nicht vor, dass personenbezogene Daten aus der EU physisch innerhalb der EU verbleiben müssen – das ist ein weit verbreiteter Irrtum. Was sie verlangt, ist eine rechtmäßige Grundlage für die Verarbeitung, Datenminimierung, die Wahrung der Rechte der betroffenen Personen und die Führung genauer Aufzeichnungen über die Verarbeitungsaktivitäten, wobei Kapitel V jede Übermittlung außerhalb des EWR durch Mechanismen wie Standardvertragsklauseln oder eine Angemessenheitsentscheidung regelt. Die Regionsauswahl auf Projektebene unterstützt die in Artikel 32 der DSGVO geforderten technischen Schutzmaßnahmen und vereinfacht die Risikobewertung bei grenzüberschreitenden Übermittlungen, ist aber ein unterstützender Mechanismus und nicht die primäre Compliance-Anforderung.
• PCI DSS konzentriert sich, soweit relevant, auf die Isolierung der Karteninhaberdatenumgebung von allem anderen, starke Kryptografie, Multi-Faktor-Authentifizierung für jeden Zugriff auf diese Umgebung und kontinuierliches Schwachstellenmanagement – nicht in erster Linie auf Verfahren für backups. Eine Guardrail-Architektur unterstützt die Eingrenzung des Umfangs und eine konsistente Zugriffskontrolle, doch die PCI-DSS-Konformität erfordert nach wie vor eine gezielte, auf die jeweilige Arbeitslast abgestimmte Abgrenzung der Karteninhaberdatenumgebung.
• DORA, das EU-Gesetz zur digitalen Betriebsresilienz (Digital Operational Resilience Act), das sich vom gleichnamigen DevOps-Forschungsbericht unterscheidet, gilt seit dem 17. Januar 2025. Es umfasst Finanzunternehmen und ihre IKT-Anbieter in fünf Säulen: Risikomanagement, Meldung von Vorfällen, Tests der Betriebsresilienz, Risikomanagement bei Dritten und Informationsaustausch. Die direkte Aufsicht auf EU-Ebene gilt für IKT-Drittanbieter, die offiziell als kritisch eingestuft wurden, nicht für jeden Technologieanbieter, den ein Finanzunternehmen nutzt. Für alle anderen ergeben sich die Verpflichtungen indirekt über die vertraglichen Anforderungen und die Anforderungen zum Risikomanagement bei Dritten, die das Finanzunternehmen selbst erfüllen muss. Die Guardrail-Architektur unterstützt speziell die Säulen Risikomanagement und Tests; sie ist für sich genommen kein vollständiges DORA-Compliance-Programm.

Das Muster bei allen fünf: Sie überschneiden sich auf der Infrastrukturebene so stark, dass ein einheitlicher Satz von Kontrollmaßnahmen für jeden von ihnen tatsächlich funktioniert, aber sie unterscheiden sich in ihrer Gewichtung, und jeder hat spezifische Anforderungen, die eine „Guardrail“-Ebene allein nicht erfüllt. Die Architektur beseitigt den manuellen Aufwand auf Infrastrukturebene. Die Ermessensentscheidungen, der Umfang, die Risikobewertung und die Rechtsgrundlage bleiben Aufgabe der Compliance-Abteilung.

Der Weg dorthin ohne Neugestaltung

Das Wichtigste auf einen Blick: Der Aufbau dieser Architektur erfordert keine Umstellung aller bestehenden Dienste auf eine neue Plattform. Es geht darum, die „Guardrail“-Ebene einmalig einzurichten und neue Projekte von Anfang an darauf anzubinden, während bestehende Dienste nach und nach migriert werden.

Der Übergang, der die meisten Bemühungen um eine Compliance-Architektur ins Stocken bringt, ist die Annahme, dass jeder bestehende Dienst auf einmal umgestellt werden muss. Das ist nicht der Fall. Neue Projekte nutzen die „Guardrail“-Ebene vom ersten Commit an, wodurch verhindert wird, dass sich Compliance-Schulden weiter anhäufen. Bestehende Dienste werden migriert, wenn aktiv an ihnen gearbeitet wird – etwa im Rahmen eines Feature-Zyklus, eines Upgrades von Abhängigkeiten oder einer Sicherheitskorrektur –, und nicht in einem speziellen Compliance-Migrationssprint.

Die Reihenfolge, die am besten funktioniert, beginnt mit Zugriff und Identität, da der Zugriff in einer fragmentierten Umgebung meist der Bereich ist, in dem die Abweichungen von den Richtlinien am größten sind und in dem sich die Nachweise im Nachhinein am schwersten rekonstruieren lassen. Verschlüsselung und Protokollierung folgen ganz natürlich, da es sich dabei größtenteils um Plattform-Standardeinstellungen handelt und nicht um projektbezogene Konfigurationsarbeiten. Die Auswahl der Region und die Backup-Richtlinie kommen zuletzt, da sie am stärksten von der jeweiligen Arbeitslast abhängen und davon profitieren, wenn sie erst angepasst werden, sobald die grundlegende Ebene bereits vorhanden ist.

Wenn man in dieser Reihenfolge vorgeht, werden die Dienste bei ihrer Inbetriebnahme nahtlos in eine einheitliche Schutzarchitektur überführt, ohne dass eine einzige erzwungene Umstellung erforderlich ist. Manche lassen sich nicht nahtlos einfügen. Workloads mit ungewöhnlichen Anforderungen an Datenverarbeitung, Netzwerk oder Zertifizierung erfordern mehr Planung, zusätzliche Integration oder einen dokumentierten Ausnahmepfad – und es ist besser, diese gleich zu Beginn zu identifizieren, als sie erst mitten in der Migration zu entdecken.

Überprüfe deine regulierte Bereitstellungsarchitektur mit Upsun

Häufig gestellte Fragen (FAQ)

Müssen wir für diese Architektur unsere bestehenden Tools und Dienste aufgeben? 
Nein. Die Guardrail-Ebene regelt Zugriff, Verschlüsselung, Aktivitätsprotokolle, Regionsauswahl und backups auf Plattformebene. Es ist nicht erforderlich, Anwendungscode neu zu programmieren oder die Datenbanken, Frameworks oder Dienste zu ersetzen, für die sich ein Team bereits entschieden hat. Bei der Migration geht es darum, bestehende Projekte unter die Guardrail-Ebene zu bringen, nicht darum, sie neu aufzubauen.

Wie gehen wir mit einem Framework um, das in dieser Referenzarchitektur nicht ausdrücklich abgedeckt ist? 
Die fünf Schutzmaßnahmen – Zugriff, Verschlüsselung, Aktivitätsprotokolle, Regionsauswahl und backups – entsprechen den Nachweisen, die die meisten Compliance-Frameworks in irgendeiner Form verlangen. Finde zunächst heraus, welche der fünf Maßnahmen in deinem spezifischen Framework am wichtigsten ist, und stelle sicher, dass die Schutzebene Nachweise in dem Format liefert, das dein Auditor oder deine Aufsichtsbehörde erwartet. Bei Frameworks mit zusätzlichen anwendungsspezifischen Anforderungen, wie der Isolierung der Karteninhaberdatenumgebung bei PCI DSS oder der Säule „Resilienzprüfungen“ bei DORA, solltest du die „Guardrail“-Ebene als Fundament betrachten, auf dem du diese zusätzlichen Maßnahmen aufbaust – nicht als Ersatz dafür.

Was ist der Unterschied dazu, einfach mehr Compliance-Mitarbeiter einzustellen? Die 
Compliance-Mitarbeiter treffen nach wie vor die Ermessensentscheidungen: Sie legen den Anwendungsbereich aus, verwalten Ausnahmen, führen Risikobewertungen durch und kümmern sich um die spezifischen Bestätigungen, die ein Rahmenwerk verlangt. Was diese Architektur überflüssig macht, ist die manuelle Arbeit zur Beweissammlung, die diesen Ermessensentscheidungen zugrunde liegt – also die Woche, in der vor jedem Audit Protokolle aus verstreuten Systemen zusammengetragen werden müssen. Sie macht die Compliance-Mitarbeiter effektiver, nicht überflüssig.

Verlangsamt die Standardisierung der Schutzmaßnahmen Teams, die ohnehin schon schnell arbeiten? Im 
Allgemeinen nicht, da Schutzmaßnahmen, Zugriffskontrolle, Verschlüsselung und Aktivitätsprotokolle Dinge sind, die gut geführte Teams ohnehin bereits konsequent umsetzen. Was sich ändert, ist, dass diese nun Plattform-Standardeinstellungen sind und nicht mehr von jedem Team einzeln implementiert werden müssen, was die Teams in der Regel eher beschleunigt als verlangsamt.

Was sollte ein IT-Leiter als Erstes prüfen, bevor er dieses Modell einführt? 
Beginne mit Zugriff und Identität: Kannst du derzeit für jede Umgebung benennen, wer Zugriff hat und warum, und kannst du nachweisen, dass Zugriffsänderungen ordnungsgemäß genehmigt wurden, anstatt nur zu zeigen, dass sie stattgefunden haben? Wenn die Beantwortung einer dieser Fragen mehr als ein paar Minuten dauert oder die Überprüfung mehrerer Systeme erfordert, ist das genau die Lücke, die diese Referenzarchitektur als Erstes schließen soll.